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This  article  discusses  the  Naval  Air  Systems  Command  (NAVAIR)  distributed  team  that  became  an  example  of  how  pro¬ 
jects  can  work  together  remotely  and  be  successful  This  was  accomplished  through  the  use  of  common  processes  extended  to 
multiple,  distributed  teams,  their  coaches,  and  the  tools  used  to  automate  those  processes.  The  other  vital  area  addressed  was 
the  organisational  cultures  to  be  connected.  This  meant  an  important  understanding  of  each  other’s  assumptions,  values,  and 
styles  needed  to  happen.  This  article  is  fdled  with  observations  and  lessons  learned  from  team  members,  team  coaches,  and 
organisational facilitators  on  the  multi-site  virtual  merging  of  NAVAIR  E-2C  Hawkeye  software  developers  at  Patuxent 
PJver,  MD  with  F-14D  software  developers  at  Point  Mugu,  CA. 


The  challenge  facing  the  E-2C  program 
at  Patuxent  River  in  Maryland  in  2003 
was  one  of  simply  having  more  work  than 
the  engineers  could  perform  in  the  time 
allotted.  At  the  same  time,  engineers  at 
Point  Mugu  in  California  were  working  on 
the  F-14D  delivering  its  final  block  release 
to  the  fleet.  When  E-2C  leadership  discov¬ 
ered  the  available  pool  of  engineers  at  Point 
Mugu,  the  question  became  one  of  how  to 
successfully  combine  these  two  groups  of 
engineers  into  one  distributed  team. 

E-2C  leadership  at  the  time  was  aware 
of  the  F-14A/B/D  model  aircraft  sun  set¬ 
ting  and  the  fact  that  many  talented  soft¬ 
ware  engineers  were  becoming  available  for 
other  work.  The  F-14  Integrated  Product 
Team  at  Point  Mugu  saw  working  with  E- 
2C  as  an  opportunity  to  place  their  software 
engineers  into  a  team  with  a  bright  future. 
F-14  leadership  briefed  the  E-2C  leadership 
on  the  capabilities  of  these  software  engi¬ 
neers  as  part  of  their  effort  to  find  a  future 
home  for  them.  Their  Team  Software 

Team  Software  Process,  Personal  Software  Process,  TSP, 
and  PSP  are  service  marks  of  Carnegie  Mellon  University. 


Process™  (TSP^“)  credentials  were  so 
impressive  that  the  E-2C  program  decided 
it  was  worth  the  extra  effort  involved  in 
having  virtual  teams  employed  on  their 
upcoming  software  development  projects. 

Members  from  the  two  sites  became 
two  integrated  teams,  one  for  the  E-2C 
Mission  Computer  (MC)  and  one  for  the 
displays  on  board.  The  E-2C  Leadership 
asked  the  NAVAIR  Process  Improvement 
(PI)  enterprise  team  for  an  approach  to 
establish  this  virtual  software  engineering 
team.  They  would  start  with  TSP  to  estab¬ 
lish  a  process  engineering  framework  due 
to  its  success  with  other  NAVAIR  projects 
[1].  You  win  hear  about  three  things  in  this 
article:  TSP  and  its  ability  to  support  multi¬ 
ple,  distributed  teams,  cultural  change  and 
how  people  were  supported  as  the  distrib¬ 
uted  team  started,  as  well  as  responses 
about  how  this  effort  evolved  and  what 
they  think  of  it  now  as  they  stiU  continue  to 
work  together  five  years  later. 

TSP 

To  start,  we  will  provide  a  quick  review  of 


basic  TSP  followed  by  the  extensions  of  the 
multiple,  distributed  team  version  applied  to 
E-2C.  The  basic  TSP  is  a  software  engineer¬ 
ing  process  framework  created  by  the 
Software  Engineering  Institute  (SEI)  to  help 
a  team  plan  its  work  and  then  work  that  plan 
through  collection  of  measures,  regular  com¬ 
munications,  and  replanning  at  milestones 
along  the  way  to  delivery  of  products  [2]. 
The  fundamentals  are  displayed  in  Figure  1. 

The  TSP  starts  by  building  a  common 
language  between  software  engineers  on  a 
team  by  training  them  in  the  Personal 
Software  Process™  (PSP'^^)  that  they  will  each 
use  [3].  This  training  uses  both  lectures  and 
exercises  so  that  engineers  gain  knowledge 
and  experience  in  the  use  of  the  process 
scripts  they  will  use,  collection  of  basic  mea¬ 
sures  used,  and  derivation  of  metrics  from 
those  measures  so  that  project  plans  and 
acmals  can  be  brought  together  to  have 
quantitative  project  status  on  a  weekly  basis. 

The  beginning  of  the  real  project  work  is 
the  launch  [4].  It  Is  a  set  of  nine  very  struc- 
mred  and  detailed  planning  meetings  that 
start  by  communicating  with  project  stake- 


F-14D  Tomcat  —  United  States  Navy’s  primary  maritime  air  superiority 
fighter,  fleet  defense  interceptor  and  tactical  reconnaissance  plaform  from 


1974  to  2006. 


E-2C  Hawkeye  —  Navy’s  all-weather,  carrier-based  tactical  battle  manage¬ 
ment  airborne  early  warning,  command  and  control  aircraft  for  the  Carrier 
Strike  Group  and  Joint  Force  Commander. 
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Figure  1 :  TSP  Approach  of  Training,  Planning,  and  Operations 


holders  to  obtain  needs,  wants,  and  desires. 
From  this  the  team  will  proceed  with  identi¬ 
fication  of  roles,  goals,  products,  and  ser¬ 
vices.  Then  they  proceed  with  the  top-down 
and  bottom-up  plans  necessary  to  have  each 
member  of  the  team  own  a  balanced  work¬ 
load  of  tasks  that  allow  two  to  four  tasks  to 
be  accomplished  each  week.  This  way,  when 
the  team  becomes  operational  after  launch 
each  person  is  able  to  know  if  they  are  mak¬ 
ing  progress  or  if  they  need  to  shift  tasks 
with  their  teammates. 

While  Figure  1  shows  a  launch  happen¬ 
ing  at  requirements  time,  a  project  may  actu¬ 
ally  start  TSP  anywhere  in  its  life  cycle  based 
upon  the  next  opportune  time  to  do  so.  For 
example,  if  a  project  wishes  to  apply  TSP  for 
the  first  time  and  is  currently  developing 
requirements,  then  it  will  obtain  the  TSP 
training  sometime  shortly  before  the  high- 
level  design  phase  and  then  launch  after 
requirements  are  complete. 

Another  feature  of  TSP  is  planning  an 
entire  project  from  top-down  at  the  begin¬ 
ning  and  then  re-planning  as  milestones 
along  the  way  are  reached.  This  is  because 
the  level  of  detailed  planning  done  in  TSP 
should  not  exceed  three  to  six  months  due 
to  reasonable  horizons  of  work  being 
done  and  the  idea  of  working  from  mile¬ 
stone  to  milestone.  While  Figure  1  shows  a 
simple  waterflow  model,  a  team  may 
instead  choose  other  strategies  where 
example  project  cycles  develop  iteratively 
functional  versions  of  a  project.  A  typical 
multi-year  project  will  go  through  several 
cycles  of  bottom-up  planning  as  it  moves 
from  one  milestone  to  the  next. 

Distributed  Team 

To  recap,  the  E-2C  program  was  doing  two 
things  with  TSP.  It  was  using  multpk  project 
teams  to  deliver  its  product  and  in  virtual 
teams  that  were  distributed  between  Maryland 
and  California.  Each  project  team  is  self- 
coordinated,  with  each  member  acting  in 
one  of  several  technical,  support,  or  lead 
roles  that  coordinates  all  these  efforts.  Each 
of  the  E-2C  project’s  leads,  planning  coordi¬ 
nators,  and  quality  coordinators  would  come 
together  in  key  parts  of  a  multi-team  launch. 
Planning  coordinators  came  together  before 
and  after  top-down  and  bottom-up  plan 
meetings  to  check  status  and  test  any 
assumptions.  Quality  managers  meet  after 
the  quality  plans  have  been  generated  to  do 
the  same.  Also,  at  the  end  of  each  day  of 
launch  the  leadership  team,  consisting  of 
each  project  lead  and  the  coaches,  convene 
to  check  status  and  discover  any  horizontal 
issues  that  may  affect  each  other. 

Shown  in  Table  1  is  recent  data  from  the 
E-2C  distributed  team  plans.  Teams  were 
constructed  based  upon  expertise  and  inter¬ 


est  of  engineers.  The  E-2C  teams  as  shown 
have  a  good  handle  on  their  plans  and  prod¬ 
ucts.  These  teams  effectively  planned  their 
work  every  four  to  six  months  to  the  level  of 
granularity  as  described  previously.  These 
launches  were  conducted  with  the  smaller 
portion  of  the  team  typically  traveling  to 
allow  the  entire  team  to  get  together.  This 
face-to-face  planning  style  was  vital  to  main¬ 
taining  trust  in  the  virtual  team. 

Operationally  these  teams  know  where 
they  are  with  ongoing  weekly  communica¬ 
tions  via  teleconference.  These  teams  chose 
to  break  up  their  weekly  communications. 
The  first  is  a  TSP  data-driven  meeting  to 
track  progress,  as  shown  in  Table  2  (see  page 
6).  The  other  weekly  teleconference  meeting 
is  used  to  discuss  technical  issues.  The  key  is 
that  these  teams  are  planning  their  work  and 
then  working  those  plans  for  constant 
improvement. 


Cultural  Change 

To  address  the  culture  change  needed  to  join 
the  two  teams,  the  NAVAIR  Organizational 
Development  (OD)  team  would  work  the 
people  issues  as  the  PI  team  focused  on 
processes.  NAVAIR  sites  had  traditionally 
been  perceived  as  competitors  to  each  other; 
this  is  a  difficult  barrier  to  break  down  as 
many  of  our  working  systems  stfll  support 
this  perception.  Also,  the  folklore  within 
each  site  includes  stories  of  past  competi¬ 
tion.  We  needed  new  stories  of  successful 
collaboration  to  replace  the  competition  sto¬ 
ries.  This  team  saw  the  possibilities  and  we 
buflt  on  that. 

Part  of  the  challenge  in  this  effort  was 
the  culture  ingrained  at  each  NAVAIR  site.  A 
Software  Support  Activity  (SSA)  maintains 
and  delivers  the  software  needed  to  bring 
high  tech  capabilities  to  today’s  advanced  air¬ 
craft.  Without  software,  the  aircraft  would  be 


Table  1:  E-2C  Distributed  Project  Teams 


Team 

Members 

Project 

Project 

Type 

Pax 

Point 

Mugu 

Tasks 

Weeks 

Tasks/ 

Eng/ 

Week 

Cycle 

Complete 

Date 

Hours 

(planned/ 

actual) 

Earned 

Value 

(planned/ 

actual) 

A 

8 

4 

780 

16 

4.06 

1 2/2006 

1.97 

1.37 

A 

8 

4 

800 

24 

2.78 

7/2007 

0.95 

1.22 

B 

4 

12 

1788 

24 

4.66 

1 2/2006 

1.13 

1.18 

B 

4 

12 

1713 

24 

4.46 

5/2007 

1.12 

1.06 

A=Advanced  Control  Indicator  Set  B=MC 
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□ 

What’s  happening  outside  the 

project? 

□ 

Each  role  coordinator  reports 

□ 

Goals 

□ 

Risks 

□ 

Project  status  (plans  vs.  actuals) 

□ 

Upcoming  tasks  and  special  events 

Table  2:  Weeklj  TSP  Team  Meeting  Typical 

Agenda 

unable  to  deliver  today’s  precision  weapons. 
Traditionally,  members  of  an  SSA  were  co¬ 
located  because  aU  had  to  be  close  to  the  sim¬ 
ulation/  test  lab  where  they  produced/ modi¬ 
fied  the  software  and  tested  it.  For  example, 
F/A-18  and  AV-8B  at  China  Lake,  F-14D  at 
Point  Mugu,  E-2C  at  Patuxent  River,  MD, 
and  so  forth.  With  the  advances  in  technolo¬ 
gy,  the  avadabiiity  of  high-speed  communica¬ 
tions  lines  has  gone  up  and  costs  have  low¬ 
ered,  allowing  virtual  teaming  to  become 
much  more  common.  If  anything,  it  is  now 
the  culture  —  norms,  customs,  traditions  — 
that  seem  to  stand  in  the  way  of  increasing 
the  use  of  virtual  teams. 

E-2C  leadership  announced  from  the 
start  that  the  teaming  arrangement  would  not 
be  one  of  developer  and  subcontractor,  but 
rather  a  single  integrated  team  —  a  true  part¬ 
nership.  One  benefit  from  this  partnership  is 


increased  resources.  Pax  needed  more  engi¬ 
neers  and  Point  Mugu  needed  more  work. 
Without  that  relationship,  they  would  not 
have  been  able  to  give  the  fleet  aH  the  want¬ 
ed  and  needed  functionality  -  the  benefit 
being  that  E-2C  would  generate  more  work 
for  itself  and  help  the  program  grow.  In  the 
end,  the  program  thought  it  could  be  used  as 
an  example  to  follow  when  considering  a 
successful  multi-site  team. 

According  to  the  OD  team,  the  challenge 
was  pretty  clear;  NAVAIR  has  been  produc¬ 
ing  software-intensive  products  for  decades 
so  the  knowledge  for  software  exists  with  the 
people  aU  across  the  NAVAIR  sites.  Bringing 
teams  together,  rather  than  hiring  new  people 
into  a  site,  is  more  efficient  because  the  cost 
of  recruitment  and  training  is  not  needed. 
Instead,  the  investment  is  made  in  building  a 
team  rather  than  in  training  in  the  software 
domain.  The  people  who  came  together  on 
this  team  already  had  the  NAVAIR  knowl¬ 
edge  and  knew  how  to  develop  good  quality 
software.  They  just  needed  to  learn  how  to 
work  together  from  across  the  country. 

Team  Building 

Budding  the  virtual  teams  was  accomplished 
with  two  initial  events.  The  first  was  a  three 


day  initial  gathering  in  June  2003  designed  to 
start  the  building  of  a  new  common  culture. 
Its  objectives  were  the  fodowing: 

1.  Get  every  team  member  to  meet  and 
greet,  get  to  know  each  other,  and  have 
some  fun. 

2.  Share  history  of  each  subgroup  and 
establish  a  vision  of  the  future  for  this 
newly  formed  team. 

3.  Establish  team  operating  principles 
and  obtain  team  agreement  on  basic 
operations. 

4.  Identify  communications  methods  and 
processes  for  initial  team  operations. 
To  meet  these  objectives,  the  first  day 

was  conducted  as  a  set  of  outdoor  activi¬ 
ties  to  get  everyone  to  know  each  other 
and  have  fun.  Activities  were  conducted  in 
a  park  on  base  at  Pax  and  included  various 
games  such  as  the  following: 

•  Celebration  of  success  -  developing 
ways  to  do  so. 

•  Reflection  —  what  in  your  past  will 
contribute  to  success. 

•  Picture  cards. 

•  Ah-So-Koh  circle. 

•  Newspaper  talk  —  sharing  information. 

•  Climbing  wall. 

•  Hula  hoop  lift. 

•  Reflection  —  personal  plan,  etc. 


Table  3:  Individual  Feedback 


Project 

Location 

Comments 

Mission 

Computer 

Point  Mugu 

Team  building  was  valuable:  “Although  some  distrust  levels  were  still  around  after  the  team  building 
event,  the  event  lay  the  foundation  for  the  groups  to  build  a  functional  team  to  achieve  the  common 
goals.’’ 

Foreign 

Military 

Sales 

Point  Mugu 

Had  his  doubts  initially  but  realized  E-2C  was  serious:  “...when  1  saw  the  effort  going  in  at  PAX  to 
provide  the  training,  tools,  and  resources  necessary  to  get  the  job  done  here  at  Point  Mugu,  1  knew 
management  was  really  supporting  this.’’ 

Mission 

Computer 

Point  Mugu 

Results  were  the  key:  “After  successfully  delivering  many  projects  within  schedule  for  the  Version-5  fleet 
release,  1  realized  that  the  distributed  approach  was  going  to  work.  If  people  did  not  work  together  as  a 
team  to  solve  problems,  they  simply  could  not  achieve  such  results.  Since  it  was  the  first  project,  working 
together  to  deliver  Version-5  was  the  most  difficult.  Several  projects  after  that  were  flying  smoothly.’’ 

Display 

Pax 

Attributes  team  success  to  TSP.  Has  been  a  team  member  since  March  2004,  develops  requirements 
and  detailed  design  documentation:  “TSP  provides  organization  and  communications;  as  a  developer, 
you  know  exactly  what  is  expected  from  you  from  the  start  of  the  project.  Both  managerial  and  team 
expectation.  In  order  to  accomplish  those  objectives,  you  need  to  have  strong  communication  within  the 
teams.’’ 

Mission 

Computer 

Point  Mugu 

Technology  was  an  issue:  “1  think  the  biggest  challenge  was  and  is  operating  a  classified  network  across 
the  country.  Not  so  much  because  the  technology  is  not  there,  but  because  of  all  the  security  hoops  that 
we  have  to  go  through  to  get  our  network  approved.’’ 

Leadership 

Pax 

Technology  also  helped:  “Technology  aided  in  allowing  this  team  to  work  together.  We  were  able  to 
establish  a  network  across  country,  which  allowed  the  use  of  a  common  data  repository  and  common 
processes  to  be  used.  For  example,  everyone  at  both  sites  used  the  same  configuration  management 
system.’’ 

Display 

Pax 

Had  previous  experience  on  a  distributed  team,  and  did  not  like  it:  “It  was  not  well  coordinated  and  1 
always  felt  like  we  were  the  poor-stepchildren  in  the  process.’’  This  time  the  approach  was  completely 
different:  “There  is  high  coordination  and  management  attention  to  the  issues  involved  technically  in 
making  it  work  smoothly.  1  know  that  this  time  1  am  on  the  big  side  (East  Coast)  and  so  that  may  make 
things  different,  but  1  think  that  there  is  much  more  sense  that  the  West  Coast  folks  are  real  team 
members,  not  just  hired  help.’’ 

Mission 

Computer 

Point  Mugu 

Importance  of  communicating  across  the  sites:  “The  biggest  challenge  was  communication.  Several 
conference  calls  and  meetings  between  the  two  sites  took  place.  Several  visits  were  made  by  team 
management  so  they  could  know  every  team  member  and  build  the  bridge  between  them.  These  efforts 
definitely  helped.’’ 
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1 .  Have  a  project  plan.  Everyone  should  know  the  mission  and  goals.  Each 
member  should  know  who  Is  responsible  for  what  and  when. 

2.  Learn  about  available  resources  from  each  other.  How  many  developers  are 
available  and  what  skills  or  talents  does  each  individual  have?  What  equipment 
and  tools  are  there  for  development  and  testing? 

3.  Communicate  with  each  other  and  communicate  often.  Plan  weekly 
meetings,  plan  face-to-face  meetings,  e-mail,  and  call  often. 

4.  Trust  each  other.  Team  members  should  respect  and  understand  each  other. 

5.  Share  information.  Team  members  should  share  what  they  know  and  what 
they  learn  with  everyone  else. 

6.  Work  to  your  plan  and  goals. 


Table  4:  Six  factors  That  Produce  Success  for  a  Multi-Site  Team 


The  second  and  third  day  events  were 
conducted  indoors  with  the  goal  of 
increased  understanding  through  historical 
and  present-day  perspectives.  Many  of  the 
outcomes  of  the  games  and  advenmres  of 
the  first  day  would  be  available  for  use  in 
this  second  and  third  day  of  team  building. 
Activities  included  the  following: 

•  Team  introductions. 

•  Team  history. 

•  E2C  lab  tour. 

•  Myers-Briggs  Type  Indicator  workshop. 

•  Strengths /weaknesses /opportunities  / 
constraints  chart  developed  by  the 
team. 

•  Gap  analysis  determined,  solutions  pro¬ 
posed,  and  actions  assigned  to  team 
members. 

•  Team  members  built  joint  vision  for  the 
future. 

•  Team  members  drafted  team  agree¬ 
ment,  mission,  and  vision. 

The  second  event  was  performed  about 
eight  months  into  the  projects  in  February 
2004.  A  follow-up  with  E2-C  project  teams 
was  performed  by  conducting  confidential 
interviews  at  both  sites.  From  topics  that 
emerged,  a  set  of  team-building  topics 
were  presented  to  team  leaders  for  possible 
follow  up.  One  of  the  most  impressive  dis¬ 
coveries  from  the  confidential  interviews 
was  that  communication  between  the  two 
sites  and  team  members  was  going  well  -  a 
big  plus! 

Observations 

While  engineering  process  and  cultural 
change  were  important  in  making  this  E-2C 
multi-distributed  team  get  started,  we  were 
most  interested  in  the  people  themselves  and 
what  they  thought.  With  evolving  require¬ 
ments  and  launches  accordingly,  these  pro¬ 
jects  stiH  exist  and  operate  in  very  much  the 
same  distributed  way  as  they  started  nearly 
five  years  ago.  While  that  says  a  lot,  we  want¬ 
ed  to  know  what  real  participants  said  (see 
Table  3). 

A  member  of  one  E-2C  team  did  a  good 
job  showing  some  of  the  fundamental  places 
where  PI  and  cultural  change  (see  Table  4) 
took  place.  Individuals  of  a  team  located  in 
different  places  must  know  and  trust  each 
other  to  plan  their  work  and  then  track  it.  To 
do  so,  historical  data  must  be  collected  and 
used  for  tracking  and  improved  planning. 

Conclusions 

It  is  important  to  understand  that  real  people 
are  the  key  to  any  technology  improvement 
being  successful,  especially  when  it  is  a  dis¬ 
tributed  team.  The  important  thing  for  read¬ 
ers  to  realize  is  that  their  situation  could 
accomplish  the  same  great  success  with  the 
buy-in  of  people  from  their  organization. 


The  immediate  result  was  the  F-14D 
engineers  were  given  a  new  lease  on  life, 
while  E-2C  welcomed  some  incredibly  weD- 
versed  and  knowledgeable  people  into  their 
program.  Long-term  results  (continued 
excellence  in  delivering  software  products  to 
the  Fleet)  show  that  people  with  similar  train¬ 
ing  and  skills  can  move  laterally  in  an  organi¬ 
zation  and  continue  to  make  a  solid  contri¬ 
bution.  Finally,  the  overall  experience  shows 
that  two  separate  organizations  must  remem¬ 
ber  the  importance  of  considering  cultural 
factors  when  bringing  teams  together. 

As  for  the  fumre,  it  is  full  speed  ahead, 
and  more  of  the  same  for  the  E-2C  multi-site 
team.  With  initial  concerns  a  thing  of  the 
past,  the  E-2C  team  can  fully  focus  on  the 
Hawkgye  mission.  E-2C  is  right  on  target  and 
they  set  a  great  example  for  others  to  follow 


in  proving  that  miles  don’t  matter  when  it 

comes  to  having  a  successful  Integrated 

Product  Team.^ 
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